File repositories, or depots, are commonly used to store file versions in a version control system. A versioning unit, as used herein, is an atomic unit with respect to change, collision detection and merge scope, and is always transported as a whole. Development tools map their development artifacts to depot files in such a way that one versioning unit maps to one depot file. This ensures that a collision or conflict on a versioning unit will be reflected as a collision or conflict on the corresponding file in the depot.
Modeling tools (e.g. Webdynpro) may be forced to map model elements which logically belong together (i.e., to one versioning unit) to multiple files due to restrictions enforced by the development environments on which the modeling takes place. This leads to a situation where concurrent changes to a versioning unit are not necessarily reflected as a file level collision.
For example, in FIG. 1, versioning unit 110 is mapped to two files A and B. Both files are at version 1, hence the file designations A1 and B1 shown in the figure. A first user edits versioning unit 110 and his changes are reflected by changes in file A only, thus creating version 2 of file A (i.e., A2). At the same time, a second user also edits versioning unit 110, but his changes are reflected by changes to file B only, thus creating version 2 of B (i.e., B2). The first user checks-in his changes. The second user subsequently checks in his changes and the check-in finishes without any collisions or conflicts.
Each user, from his own isolated point of view, made consistent changes to versioning unit 110. Indeed, states 120 and 130 in FIG. 1 bear out the perceived consistencies. However, the combined changes could bring file B into an inconsistent state inasmuch as state 140 was not created by either of the two users and is an untested mix of the two changes. If user B's changes result in an inconsistent state (e.g., state 140), it becomes incumbent on the version control system to catch the collision and force the second user to merge his changes on versioning unit 110 with the changes made by the first user. However, a traditional version control system is not able to detect the collision in this case because the collision scope is a single file.
In addition to the example problem described above, several other scenarios can also cause collisions and/or conflicts that can go undetected and/or unresolved by traditional conflict management systems.